Day 1 - 為什麼你需要一個 AI 產品助理？

週一早上，客服轉來二十則回饋，業務又問競品的新功能，下午還要交一版 PRD。
產品經理缺的通常不是「再多一個聊天視窗」，而是把資料變成可檢查成果的穩定流程。

今天要解決的問題

這 30 天，我們要打造一套 AI 產品工作流。它會協助整理競品、清洗回饋、草稿 PRD、描述 Demo、分析數據與追蹤情報；產品經理仍負責定義問題、補足證據、審查推論與做決策。

這種分工呼應 GOV.UK 服務手冊對使用者研究的要求：需求應建立在研究證據上，意見與建議須視為待驗證假設。本文的工作台是作者為這個系列設計的實作框架。

差別在於使用方式。一次性問答通常是：貼資料、問「幫我分析」、複製答案，幾天後再重來。工作流則明確定義：

1. 輸入：資料從哪裡來，哪些可當事實。
2. 任務：這次要分類、比較、起草，還是檢查。
3. 輸出：下一位協作者需要什麼格式。
4. 審查：誰確認內容，依據是什麼。
5. 沉澱：哪些 Prompt、模板與判準值得留下。

AI 很適合處理大量文字、套用格式、提出候選分類；但它無法替團隊確認真實世界，也不承擔產品結果。文件寫得完整，不代表問題值得解決；分類看來整齊，也不代表分類有產品意義。

判斷一項工作是否適合先交給 AI，可以看三個條件：輸入能否清楚提供、輸出能否由人驗收、錯誤能否在進入決策前被發現。像是把有編號的回饋整理成表格，三項都容易做到；像是決定年度產品策略，牽涉未寫進文件的承諾、資源與風險，就不該只靠模型輸出。先畫清楚責任邊界，往後導入工具時才不會把速度誤認成品質。

用 FlowBoard 建立共同案例

本系列使用虛構 B2B SaaS「FlowBoard」。它服務 10–50 人團隊，提供專案協作功能。團隊觀察到新成員加入工作區後，常不知道下一步該做什麼，因而把「改善新成員啟用流程」選為產品題目。

以上產品、回饋、指標與限制，都是教學用模擬資料，不代表真實研究。這個標記很重要：AI 可以整理提供的材料，不能把模擬案例變成市場事實。

接下來的資料會沿同一條鏈累積：

產品情境卡
  ↓
競品畫面觀察 → 功能／流程／假設 → 機會點
  ↓
使用者回饋 → 問題分群 → 需求卡片 → 優先級
  ↓
PRD → Demo → 驗收 → 數據分析
  ↓
情報追蹤 → Skill → 自動化流程

每一步都保留原始輸入、AI 輸出與人工修訂。
這讓團隊能追問：「這個結論從哪裡來？」也能在新證據出現時回頭修正。

先把工作交代清楚

即使第一天還不請 AI 執行分析，也可以先用這個 Prompt 盤點可交給 AI 的工作：

背景：
我是產品經理，正在處理【產品／專案】。

任務：
請把以下工作拆成「輸入、可由 AI 協助的處理、預期輸出、人工決策」。

輸入：
【列出目前工作，例如整理客服回饋、撰寫 PRD】

限制：
- 不假設未提供的資料。
- AI 不替我決定需求是否值得做。
- 資訊不足時列為待確認，不自行補寫。

輸出：
使用表格，欄位為工作、輸入、AI 可協助、人工必須負責、可保存的產出物。

範例輸入與輸出

輸入：「整理新成員不知道下一步的客服回饋。」AI 可先產生如下草稿：

這列沒有宣稱問題已成立。它只把工作界面說清楚。

人類需要檢查什麼

建立工作流時，先守住四條線：
敏感資料是否能交給所用
服務來源與查閱日期是否保留
事實、推論、建議是否分開；
最終決策是否有負責人

若輸入本身偏誤，AI 只會更快整理偏誤。

今天選一個 FlowBoard 題目，高頻、輸入相對固定、輸出可驗收的任務跑通。

每次交付前，再做一次最小檢查：輸出能否回到來源？不確定性是否留在文件裡？下一位接手者是否知道該做什麼？若三題有一題答不出來，工作流還沒完成，只是多了一份 AI 文字。

今天的產出物：30 天 AI 產品助理總藍圖